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ABSTRACT 


This paper presents a discussion of a specific information system, the 
Advanced Data Management (ADAM) system, which was established to 
help the designers and users of large computer-centered data-base systems. 

The historical background of information systems is included to provide 
a foundation for discussing the concepts and techniques of ADAM. An 
application of the ADAM system to a real problem is presented to 
illustrate the usefulness and practicability of the ADAM design philosophy. 

The main point which the authors wish to establish is that computer-centered 
data-base systems as exemplified by ADAM provide a useful and more advanced 
philosophy concerning dato-base systems development than currently exists. 
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COMPUTER-CENTERED DATA BASE SYSTEMS 


Information Systems exist in many forms and are used for many 
applications. Such systems combine people and computers to provide 
commanders and their staffs with information about personnel, material, 
intelligence, and weapons. 

This paper presents a discussion of a specific information system, the 
Advanced Data Management (ADAM) system, which was established to 
help the designers and users of large computer-centered data-base 
systems. The historical background of information systems is included 
to provide a foundation for discussing the concepts and techniques of 
ADAM. An application of the ADAM system to a real problem is 
presented to illustrate the usefulness and practicability of the ADAM 
design philosophy. 

The main point which the authors wish to establish is that computer - 
centered data-base systems as exemplified by ADAM provide a useful 
and more advanced philosophy concerning data-base systems development 
than currently exists. 

OVERVIEW 


Although information systems have been developed by operatirnal 
users, specialized contractors, and Air Force Systems Command, all 
development efforts have utilized essentially a direct approach. The 
eventual user identified his requirement, and the requirement was then 
translated into detailed design by specialists, the system designers. 

The detailed design was used in the production of an actual information 
system usually by a third group of specialists, computer programmers. 
As the original requirements moved from originator to the specialists, 
they were subjected to interpretation and change resulting from simple 
communication problems. Each specialist was called upon to make 
design decisions which influenced the eventual system's capability. 

The decisions were often made without knowledge of the requirement. 
Even if systems went from originator to final producer totally unchanged, 
the time lag involved often meant that the original requirement had 
changed. Thus, this direct approach which went from requirements to 
design to final system produced results wliich did not totally satisfy 
the military requirement. 




In the development of weapons systems and support equipment, testing 
in the early design phas is and evaluation of prototypes is a standard 
procedure. Such testing is often omitted for the computer programming 
sub-systems of information systems. One reason for this failure to 
test is a lack of adequate laboratory tools. The ADAM system was 
built by the MITRE Corporation for the Electronic Systems Division, 

Air Force Systems Command, to act as a test bed for information 
systems during their conceptual, definition, and design phases. ADAM 
permits the user and system designer to build a functional prototype of 
the proposed system in a laboratory environment. Tests can be 
performed on the prototype to determine if the logical design satisfies 
the user's actual requirement. In particular, the prototype building 
and testing provides a means of communication between the user and 
the system designer. It also permits the identification of elements 
in the user's requirement which are likely to change with time. 

To prove the advantages and usefulness of the ADAM system to the 
design and development of information systems required its utilization 
on a real application. A prototype of an information system which 
will assist in officer personnel assignment was one of the first real 
applications of the ADAM system. The final information system will be 
developed utilizing a classic development approach of design, test, 
evaluate, and redesign rather than the typical direct approach used to 
build previous information systems. Only by providing the user and 
system designer with testing tools such as ADAM can the classical 
approach be utilized. 

The Man-Job-Match project, which was responsible for the prototype 
of the desired information system, was initiated by the Deputy Chief of 
Staff for Personnel, Hq USAF as a part of a total program associated 
with officer assignments. Air Force Systems Command through the 
Electronic Systems Division prepared the prototype system within 
ADAM. The basic problem was to design and develop a computerized 
assignment system which meets the requirements and objectives of the 
long range personnel management systems. 

The specific details of the system and the techniques to accomplish 
them were not fully known when work first began. Therefore, the 
design for the prototype was not totally defined for the system designer 
and was subject to modification caused by clarification of personnel 
policies and objectives by the user. 


2 




The user supplied the data, the general system logic, and the 
operating concepts from which a system was to be designed. The data 
was the fundamental element of the system. It consisted of information 
about men, information about jobs, and current personnel assignment 
policies. Approximately 4. 5 million characters of man and job data 
were used in the development effort. 

The general logic description defined the assignment process very 
superficially without regard to technical requirements. The process 
was described in four functional steps: 

1. Find men available for reassignment and determine vacant jobs. 

2. Evaluate everv available man's qualifications against every 
vacant job's requirements. 

3. Determine assignment. 

4. Transfer assignment results to the man and job files. Application 
of the appropriate personnel policies to each step furnished sufficient 
clarification for the system designer to begin his efforts. 

The problem which the designer faced was how to develop a design 
which accomplished the ultimate goal of the project and satisfied the 
operating concepts of the user. The operating concepts were very 
general, but posed some very pointed design questions. Four concepts 
of particular interest were: 

1. The prototype system had to be responsive to the manager's 
needs. 


2. The assignments produced by the model had to satisfy the 
manager's concept of a good assignment. 

3. The model had to be developed to fully demonstrate a variety of 
assignment actions, 

4. The model had to be a dynamic system with the capability to 
simulate complete movement of a representative force over a designated 
period of time. 

Many explicit functions which were implied by these guidelines had to be 
accommodated. 
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It was the designer's job to assure that each of the user's requirements 
were incorporated in a comprehensive, functional model. The basic 
characteristics which the designer was required to accommodate were: 

1. A large data base consisting of approximately 4. 5 million 
characters of information about Air Force men, jobs, and personnel 
policies. 

2. The capability to retrieve specific information from vast amounts 
of data such as in the determination of available men and vacant jobs. 

3. Computational requirements at various points within the system. 

One type of computation consisted of simple arithmetic operations for 
determining qualification weights for men versus jobs. Another was a 
complex optimization process for determining the assignments of men 
to jobs. 

4. An effective data manipulation capability to accomplish large 
volume updates. Updates were based on the assignments produced by 
the system and required placement of data into man and job records 
to reflect projected actions or actual assignment transfers. 

5. A report generation facility to satisfy the manager's need for 
information about the system. Hard copy or cathode-ray-tube displayed 
reports about men, jobs, assignment results, and system status for 
off-line or on-line evaluation were i perative. 

These five characteristics are those associated with a class of 
information systems which are called data-base systems. Such systems 
are also referred to as data management systems or information storage 
and retrieval systems. 

Because the Man-Job-Match project incorporates requirements which 
correspond to the defining characteristics of data-base systems, it 
might be considered typical of a class of problems for which data-base 
systems are well suited. ADAM is a system which contains generalized 
techniques for accommodating data-base systems characteristics. It 
provides a new design approach to data-base systems which was applied 
to the Man-.* 'b-Match effort. A discussion of the application is pre¬ 
sented in a iacer section oi the paper. 


BACKGROUND 


Data-base systems have been used in numerous applications. Because 
of the lack of design tools, the implementations of these data-base 
systems have not been accompanied by the testing of the design against 
the application's requirements during the early stages of development. 

The ADAM system was built to permit the testing of data-base systems 
in their design phase, thus allowing a designer to follow a more orderly 
development approach. 

A background discussion which describes both the background of 
data-base systems and the technological evolution of these systems will 
provide a context in which to associate ADAM with related efforts. 
Following the background discussion, the characteristics of ADAM will 
be presented as well as an actual example of the use of ADAM in the 
design of a data-base system, the Man-Job-Match prototype. 

To associate ADAM with related efforts in data-base systems, a 
brief sketch of the evolution of such systems during the last few years 
is needed. Let us begin by examining the range of applications of 
data-base systems. After a discussion of applications, the effects of 
technological developments in the computer field on data-base systems 
will be explored. 

DATA BASE SYSTEMS' APPLICATION'S - MILITARY AND BUSINES S 

One of the earliest applications of computers was in the area oi 
finance. Today, no one is surprised to find payrolls calculated by 
computers and to have company books on magnetic tape. Computerized 
military finance systems have been utilized for years. The applications 
can all be considered either a special purpose data-base system or 
utilization of a general purpose data-base system, depending upon how 
a particular application was implemented on the computer. Calculating 
a payroll requires: 

1. A data base of employees. 

2. A capability to retrieve and select employees. 
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3. Computational routines for determining the actual pay. 

4. Data manipulation capability to handle status changes. 

5. A report generation facility to present results and prepare the 
actual checks. 

In other words, a payroll system requires the five characteristics of 
data-base systems. Another early application of computers within both 
the military and the business world was in the area of logistics. 

Current literature is filled with talk of totally computelrized logistics 
systems for business. Such systems would continually hnonitor 
inventories by initiating purchase requests when inventory levels reach 
appropriate points. These systems in turn would keep track of projected 
deliveries and would log the stock into the system upon arrival as weli 
as sending follow-up requests on late deliveries. The reason such 
systems are discussed as being within the current technology is that 
computer applications which perform these functions have been operating 
for several years. The essential characteristics of any of the logistics 
applications are the same as those of data-base systems. The Require¬ 
ments Computation System of the Air Force Logistics Command (1) 
or the Air Force base supply system are excellent examples. 

DATA BASE SYSTEMS' APPLICATIONS - MILITARY SUPPORT 


The applications of data-base systems have not been limited to 
those areas which are common to both the military and business, such 
as finance and logistics. Intelligence data have likewise been handled 
by data-base systems for several years. (2) An Intelligence Data 
Handling System (IDHS) (4) exists for both the IBM 141 p and the IBM 
7090/7094 computers and is utilized within the Air Force. The Navy 
has, during the last five years, developed several data-base systems 
to aid in the handling of intelligence data. 

Reliability and maintainability data on weapon systems is handled at 
the Ballistic Systems Division by a data-base system. A large and 
sophisticated data-base system is being developed for the Reliability 
Center at the Air Force Systems Command's Rome Air Development 
Center. ( 3) The assignment of airlift aircraft is still another example 
of a military application of data-base systems. The preceding examples 
are in the areas of military support applications. 
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DATA BASE SYSTEMS' APPLICATIONS - MILITARY OPERATIONS 


Data-base systems have found application even in the vital area of 
military operations by aiding the commander in maintaining knowledge 
of the status of his forces. Major elements of some of the Air Force's 
largest Command and Control systems are data-base systems. The 
473L system for Headquarters United Slates Air Force has a very 
sophistic d data-base system which is technically noteworthy of 
descript n the professional literature. (5) The system acquires, 
process* and displays data necessary for timely action decisions 
by Hq USAF and for USAF recommendations to the Joint Chiefs of 
Staff. 

A basic element in the -16SL System which transmits, collects, 
processes, and displays data to assist the Commander, Strategic Air 
Command, in commanding and controlling his forces is a data-base 
system. The interim Command and Control System used by the 
United States STRIKE Command is an on-line data-base system 
developed by the Electronic Systems Division and the MITRE Corpo¬ 
ration. (6,9) Analysis of the Semi-Automatic Ground Environment 
(SAGE) system, which operates as part of the continental air defense 
capability, has identified some of the characteristics of data-base systems 
within the system. These are just four of the examples where data¬ 
base systems have helped the commander with his status of forces. 

These examples from the operational area as well as those from 
areas of military support and business show the range of applications 
of data-base systems. With such a wide range of applications exhibiting 
similar characteristics, it is no surprise that general purpose tech¬ 
niques for handling these characteristics have been developed. In 
this sketch of the recent evolution of data-base systems, the development 
of the techniques for general purpose data-base systems should nr.v be 
described, 

GENERAL PURPOSE DATA BASE SYSTEMS 


As the utilization of computers increased, common characteristics 
of data-base systems began to be recognized. Computer hardware as 
furnished by the manufacturers came with utility computer programs to 
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aid in the new applications. The aid was in the form of general 
techniques based upon the common characteristics of data-base 
systems. By 1959 a committee of computer manufacturers and users 
in cooperation with the United States Department of Defense was formed 
to attempt some standardization and synthesis of the developments in 
data-base systems. 

One of the results produced by the committee was a set of specifications 
for a Common Business Oriented Language (COBOL). This was one of the 
first widespread recognitions of the common characteristics of data-base 
systems. The language essentially provided a mechanism for describing 
the data base, operating on the data, and specifying the form of the 
results. Computer manufacturers have since implemented many 
COBOL compilers. Subsequently, systems designers and computer 
programmers have used these COBOL compilers for many applications. 

As with any standard and technologically dependent effort, time and 
usage have identified weaknesses and deficiencies. The professional 
literature is filled with discussions of COBOL's virtues and faults, 

(7, 8) but these discussions are not germane to the current sketch. 

All that is necessary to note is that the data-base systems have continued 
to evolve for such reasons as: (a) ease of use; (b) requirement to 
handle more compLex files; (c) efficiency; and (d) "not build here" 
attitudes. Because of the continued evolution of data-base systems, 
the work of the COBOL developers should be viewed as a plateau but 
not as a termination point. Evolution from this COBOL plateau pro¬ 
ceeded along two lines: (a) techniques for improved capability of 
general purpose data-base systems for the handling of applications; 
and (b) techniques for improved man and computer communication 
during both the production of a system to handle an application and the 
operation of the application. 

DATA BASE SYSTEMS WITH IMPROVED CAPABILITY 


Both the military and commercial manufacturers of software and 
hardware have developed general purpose systems with improved 
capabilities. The Mark III system of Informatics Corporation (9) is 
an example of a new general purpose data-base system whose objective 
is easier use. General Electric in their Integrated Data Store (IDS) 
made a direct extension to COBOL so that random access devices 
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could be efficiently utilized. (9,10) The BEST system of NCR is still 
another example of a development by a commercial firm since COBOL 
was introduced in 1959. (9,11) IBM is currently implementing GIS, a 

general purpose Jata-base system, on their new series of computers, 
the IBM 360's. (12,13) 

The military, in particular the operational support activities, has 
also produced general purpose data-base systems during the last five 
years. The Intelligence Data Handling Systems (IDHS) for both the 
IBM 1410 and IBM 7090/7094 evolved during this period. (4) The ABACUS 
system which assists the Directorate for Studies and Analysis, Deputy 
Chief of Staff for Plans and Operations, Headquarters USAF is a 
recently developed general purpose data-base system. (14) 

An important characteristic of all general purpose data-base systems 
is their separation of techniques from applications. These systems have 
been prepared without a detailed knowledge of either the information in 
the data base or the operations and calculations to be performed. 

Instead of using such knowledge, the sy^ems were designed to accept 
as inputs the details of the application -- the data base and the process 
to be performed. 'There has always been some separation of the 
techniques (the computer programs) and the application (the data). In 
the general purpose systems this separation is greater than those found 
in the older data-base systems prepared for only one specific application. 

Another characteristic of general purpose data-base systems is that 
they function in the conventional mode of operation for computer 
programs, namely off-line. An application or problem is analyzed 
and the inputs to the computer are prepared. These inputs are then 
forwarded to the computer facility where they are inserted into the 
machine and results are produced. These results are then returned and 
studied. Because the entire process is lengthy, the languages of 
general purpose systems have tended to allow many options for the 
results. Usually, the rules for selecting the options are rigid and 
somewhat cumbersome to apply, so a detailed knowledge of tl. ^ 
language is required. Systems which are designed for non-program¬ 
mers actually are systems which are easy for non-programmers to 
use. This ease of learning and use is another characteristic of the 
systems previously described. Although they do require some effort 
to utilize, they are certainly easier to use than assembly (machine) 
level programming. 
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MAN/MACHINE COMMUNICATIONS IN DATA BASE SYSTEMS 


Although off-line operation is the standard mode with the current 
second generation computers, the announced third generation will make 
on-line operations more common. The man/machine interface is more 
important and vital in such on-line operations. Recognizing this important 
problem area, several general purpose data-base systems which address 
the man/machine interface have been developed in the research community. 
The techniques used within such systems constitute the other line of 
evolution from the COBOL plateau. 

The most extreme example of a data-base system which emphasizes 
the mnn/machine interface is the Advanced Experiment Sturcture for 
On-Line Planning (AESOP) developed by the MITRE Corporation. (15) 

An outstanding characteristic of AESOP is a display system which 
helps the user select the data he desires. The language used to select 
specific information is shown to him on the display scope and the system 
provides him with cues and choices as he forms a statement in the 
language. Operations and calculations upon the data may also be 
developed on the display scope through use of an associated typewriter. 
During the entire operation, the user is time-sharing the computer 
while he prepares and operates his applications. 

Another example of an on-line and time-9hared data-base system 
is the LUCID system and its follow-on, the Time Shared Data Management 
System (TDMS), both developed by Systems Development Corporation. 

(16, 17) The outstanding characteristic of LUCID is a query language 
which is very easy to learn and use. With such a language the user can 
quickly select his data and then operate upon the data outside of the 
system. Error messages and other systems aids provide a user with 
learning tools. 

A third on-line system is the Compile On-Line and GO (COLINGO) 
system developed by the MITRE Corporation (6, 18). Versions of this 
system operate on IBM 1410 and 1401's at United States STRIKE Command, 
National Range Division, and the MITRE Corporation. Although the 
system is not time-shared, a single user is provided on-line access 
through a console typewriter. The language used to operate upon the 
data base is somewhat complex but still user-oriented. An interesting 
characteristic of the system is the ability to store statements and 
processes forlater operation. This storing capability is the characteristic 
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of many time-sharing systems which gives them an appeal. A user can 
build and test a complex process on-line, then save it. When the process 
is required, all that is needed is to select it and add the parameters. 
COUNGO provides a language for describing processes on data bases 
while on-line. 

The preceding sketch has discussed the application and technological 
evolution of data-base systems during the last few years. The sole 
objective of such a discussion was to provide a frame of reference for 
a description of ADAM, its objectives and characteristics. 

ADAM, A DESIGN TOOL 


There are two major topics in any discussion of the ADAM system. 
First, functional descriptions of the characteristics of ADAM are 
required. Along with such functional descriptions, the techniques which 
are used to achieve the capability are described. The combination of 
the functional elements of ADAM into a prototype of a real application 
completes an ADAM discussion. For this discussion, the prototype 
and application to be considered is officer personnel assignment. But 
before discussing this application in detail, the first topic, the functional 
description of ADAM's characteristics, must be covered. 

Two distinct categories of user: utilize ADAM. First, there is the 
user with an operational requirement. The other is the system designer 
who wishes to utilize ADAM to build a prototype of a data-base system 
which will satisfy a specific requirement. This second category of 
users will be called the user/designer. Each type of user views the 
ADAM system differently. To the operational user, the ADAM system 
and his prototype look like one large specific data-base system which 
satisfies his requirements. To a user/designer, the distinction between 
the ADAM system and the prototype is much more definite. ADAM 
is the tool the user/designer had when he began to build. The prototype 
is all the data and special programs which the user/designer had to 
prepare, in describing the functional capabilities of ADAM, it is better 
to take the view of a user/designer. 

During any description of ADAM, an astute observer will notice 
that similarities between ADAM and general purpose data-base systems. 
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Such similarities exist because of a basic design philosophy; namely, 
the separation of the details of a problem (the data) from its solution 
(the computer programs). This philosophy is necessary in both 
ADAM and general purpose systems because detailed knowledge of 
the application was not available when the computer programs which 
comprised the system were prepared. ADAM diiers from general 
purpose data-base systems in that it incorporates another basic design 
philosophy -- an ability to accept modification at all levels of design. 

It is this second philosophy which makes ADAM a laboratory tool 
and not a production system. However, aside from lack of efficiency 
and practical limitations, nothing prevents any user from utilizing 
an ADAM prototype in a production operation. The ability to accept 
modification within a general purpose design is the major asset of 
ADAM for a user/designer. 

DATA BASE GENERATION 

In considering how ADAM functionally accepts large data bases, the 
first basic characteristic of data-base systems, both the general purpose 
and modifiable features will be discussed. To introduce a data base into 
the ADAM system and, hence, into the computer, its structure and 
data .ypes must be described in a file description language. Provided 
within ADAM is a table driven translator which permits the definition 
of any file description language. An Initial File Description Language 
is also available within the system. Thus, a user/designer can elect 
to develop, insert, and test his own file description language using 
ADAM or he may describe his data base using the existing language. 

If he elects to remain with the Initial File Description Language, the 
user/designer has modification options such as special conversions 
for specific data elements when they are inserted into ADAM. 

The user/designer can also specify special conversion and handling 
routines for specific data elements when they are retrieved and stored. 
For example, in retrieving information on radar returns, a user/ 
designer could specify that special tables are used to locate the most 
current information. Of the four real applications of ADAM, the user/ 
designer has always elected to use the Initial File Description Language 
with special conversion routines rather than prepare a specialized 
language. 
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Another feature available when a user/designer inserts the data 
base is the automatic coding of data. By designating data as having a 
certain property, dictionaries are formed which associate a number 
with each unique value of the data. These dictionaries are automatically 
used when the data are retrieved so that the user receives the same 
values that were inserted. The user/designer has the preceding 
features available within ADAM to allow him to handle a large variety 
of data bases. 

DATA SELECTION AND RETRIEVAL 

The selection and retrieval of data, the second characteristic 
of a data-base system, is handled by most systems through a query 
language. Because the process of selection and retrieval is repeated 
more often and by more users than the process of initially inserting 
the data into the system, query languages need to be more user 
onented and are more susceptible to specific requirements. As 
previously noted, current systems tend to operate in an off-line 
fashion while future systems will be on-line operations, or both. 

The ADAM system has been designed to operate (a) off-line through 
tape inputs, (b) on-line through display scopes, typewriters, and 
printers; or (c) mixed with off-line inputs sending results on-line and 
on-line inputs initiating complex off-line proces ses. 

Besides this ability to operate in any combination of modes, the 
user/designer also can develop his own query language. As in data¬ 
base description, the user/designer can either use the table - driven 
translator to specify his own query languages or utilize a query 
language, FABLE, which is provided with the ADAM system. 

Regardless of his choice, the user/designer still has another 
modification feature available; string substitution. This feature permits 
a user/designer to equate a single word to a string of words. When 
a query enters the system it is examined for these single words and 
when one is found the equivalent string of words is substituted. After 
each substitution the string can optionally be examined again for 
further substitutions. 

An additional design feature is available for those user/designers 
concerned with developing on-line user interaction through a display 
scope, a typewriter, or both. The display capability of ADAM allows 
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the user/designer to assign meaning to different display actions, for 
' example, depressing buttons or light-gun selection of an item which is 

displayed on a display scope. These assigned meanings can be 
associated with each other so that they can form a query which selects 
and retrieves data. This capability of specifying sets of display 
actions which can select data will be very useful for the user/ 
designer who will be concerned with the on-line data-base systems 

j of the future. 

! COMPUTATIONS 

| Adam provides the user/designer with two basic capabilities for 

! handling computation requirements, the third characteristic of 

1 data-base systems. The first capability is through a query language. 

As in the selection and retrieval of data, a user/designer can either 
develop his own query language for computation or use the FABLE 
language provided with the ADAM system. A difficulty with using a 
query language is that the entire computational process must be 
presented in a single statement. Thus, logical testing of the data 
| with computation performed on the test result or computations based 

, upon results previously calculated are not easily described in query 

languages. For extensive calculation, a higher-order algebraic language 
is desirable and is the other basic capability for handling computations. 
ADAM provides the user/designer with the ability to insert a FORTRAN 
program into the system to handle extensive computations. Such a 
program operates under a special monitor within the ADAM system 
and access to the data base is through special routines. Since the 
data that the FORTRAN program uses comes from the data base, 
standard input/output statements of FORTRAN are not allowed. 

Instead, data and results must be passed between the data base by 
means of special routines usually prepared by the user/designer. 

The FORTRAN program can then be initiated by a statement in query 
language. 

DATA MANIPULATIONS 


Tne query language is also ine way to handle the fourth characteristic 
of data-base systems -- many data manipulations such as in mass 
updates. The previous comments about query languages applies to 
this area. In particular, efficiency may require that such operations 
occur off-line and/or be done by special purpose routines. 
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REPORTS GENERATION 


The final characteristic of data-base systems, reports generation, 
is also handled by the ADAM system. The user/designer must prepare 
his formats off-line. ADAM is an on-line system only when it is 
acting as a prototype. While the user/designer is building his prototype 
he is usually working off-line. The report generator of ADAM performs 
similarly to most report generators. A format for a report is prepared 
which is independent of the actual data to be presented in the finished 
report. The report generator takes both the format and the data, 
combines them, and adjusts the resulting report for output to any of the 
devices of the ADAM system; i. e., printers, display scopes, teletypes, 
or typewriters. Provisions have been made in the language which des¬ 
cribes the formats to allow specia routines to be executed during the 
report generation process. This capability helps the user/designer 
prepare formats which present the data and results in ways which are 
most convenient for the user. 

During the previous discussion, the functional characteristics of 
4.DAM have beenbriefiy described. Some of the choices and capabilities 
provided a user/designer have been indicated. To demonstrate how a 
user/designer combines these capabilities, a real application should 
be considered. The prototype of the Man-Job-Match project is just 
such an application. 

MAN-JOB-MATCH: AN ADAM APPLICATION 


The initial problem that faced the Man-Job-Match project was the 
data base. The two files which constitute the major portion of the data 
base were not large or complex by operational standards, but they 
presented several difficulties when viewed from a research and develop¬ 
ment aspect. The total data base consisted of approximately 4. 5 million 
characters of data: 5400 man records of 594 characters and 5400 job 
records of 318 characters. 

The general nature of the data was important to the decisions 
regarding data base handling. There were properties which contained 
numeric codes, alpha-numeric codes, dates which required special 
conversion, and strings of alphabetic information. It was necessary 
to be able to accommodate these various oata and, at the same time, to 
facilitate the operations which were to be applied to tiiem. 
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The Initial File Description Language of the ADAM system was 
considered more than adequate for the file definition of the assignment 
system. This language provided for introducing the data types present 
in the data base: 

1. Logical property descriptions for internal coding of alpha-numeric 
codes and data strings (e. g. duty location, education specialty, special 
experience). 

i. Numeric property descriptions for storing numeric values 
(e. g. tour length, social security number, job number). 

3. Raw value property descriptions for alphabetic character strings 
(e. g. job titles, names of men). 

4. An option for using user-generated conversion routines (e. g. to 
convert the dates which appeared in various forms). 

Each of the property types except the raw value property were represented 
in the computer in a form which allows querying. 

PERSONNEL POLICY 

Introduction of the Man and Job files into ADAM satisfied most of the 
operational data base requirements of the assignment model. The 
personnel policy data presented a different problem for the user/designer. 
The difficulty was one of versatility rather than size. Policy data were 
to be used as parameters to the model. User-defined guidelines indicated 
a variable structure of policy data and emphasized that the data could change 
frequently. Repetitious groups of similar data were evident in the policy 
data. There was no way to predetermine the number of repetitions that 
might exist within one policy structure. Policy data were easily 
accommodated by the Initial File Description Language. The solution to 
the problem of frequent changes to the policy files was found in ADAM's 
FABLE query language. 

AVAILABILITY SELECTION 

Interrogation and retrieval of data was the second area of concern .'or 
the user/designer. System requirements for data retrieval were extensive. 
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The determination of available men and vacant jobs was a selective data 
retrieval action. The selection process was governed by specific require¬ 
ments expressed in qualifying (boolean) statements which were often 
complex. Thecriteria for identifying available officers for reassignment 
consisted of at least live attributes: 

1. career field and specialty 

2. current duty location by major air command area 

3. rank 

4. date of arrival at current duty station and availability date 

5. projected assignment actions 

It was necessary to form queries which would screen the entire file 
of men and retrieve specific data about those who met the criteria. 
Essentially the same process was necessary to obtain vacant jobs. 

FABLE was selectedas the language in which to implement the 
data retrieval messages. There was sufficient versatility in the language 
to describe the qualifying phrases to the detail necessary for the model's 
successful implementation. The use of string substitutions was extensive 
throughout the model. These string substitutions, as described in a 
preceding section, permitted the user/designer to equate a single word to 
a string of words. When the query entered the system all these single 
words were replaced by their corresponding string of words. The use of 
substitution made the job of the personnel manager easier as he exercised 
the model. To exercise a portion of the model, the personnel manager 
needed to type only a few words rather than a long FABLE statement. 1 he 
availability query, which consists of 15 characters when the personnel 
manager entered it, expanded to apf .•oximately a 1300 character statement. 

CRITERIA MODIFICATION 


The lengthy qualifying expression used in the queries had to be 
modified as criteria -changed. One change to an expression required that 
the entire expression be restructured. String substitutions allowed the 
user to segment criteria into individual relationsh ; ps and assign a name 
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to each component. Under this arrangement, a component (a word and 
its corresponding string of words) requiring modification could be deleted 
and redefined without affecting the rest of the expression. For example, 
in the case of determining available men, each attribute was described 
using string substitutions, "GET MAN AVAILABLE" was the query 
entered by the manager. The word "AVAILABLE" was the name of the 
highest level of qualifying expressions. The string of words which was 
substituted for the word AVAILABLE contained words which required 
further substitution. These words AFSC, GRADE, MAC ARE A, DATEAR, 
and PROJECTED were names of the specific criteria for the respective 
attributes of career specialty, grade, location by major command area, 
date of arrival on station, and projected actions. Such string substitutions 
contributed greatly to satisfying the requirement of responsiveness to 
the personel manager's needs. The personnel manager needed only to 
change the string of words corresponding to GRADE to change the 
criteria of qualification for grade. To add an entirely new criterion 
required only changing the string for AVAILABLE. Such usage of 
string substitution permitted the personnel manager to easily exercise 
the model and to easily change criteria. 

COMPU TATIONAL REQ UIRE ME N TS 


Computational requirements existed in two of the functional modules 
of the prototype. Each requirement differed greatly in mathematical 
complexity and method of data handling. These areasof difference 
identified additional capabilities required to implement the model--(l) 
a means for facilitating mathematical routines of varying comnlexity 
and (2) a flexible data manipulation capability. 

A special monitor in ADAM (COMFORT) accommodated the 
mathematical routines. However, since data input and output functions 
were excluded from the monitor, the problem of supplying data to the 
routines had to be handled by specially prepared programs. 

The computational requirements were defined as: (1) qualifying 
men versus jobs, and (2) optimizing the assignment of men to jobs. The 
first of the two was defined as a two step process. The first step checked 
to determine if a man meets the mandatory job requirements as defined 
by personnel policyand, if he did, the second step evaluated his character¬ 
istics versus the requirements of each vacant job. This procedure 
necessitated data from four sources: 
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1. a file of available men 


2. a file of vacant jobs 

3. a policy file of mandatory requirements 

4. a policy file of qualification data 

Data generated by the qualification procedure was placed into a fifth 
file. The optimization routine, which was a mathematical optimization 
process, required the data in matrix form. The resulting assignments 
and associated data were placed into still another file. 

No adequate capability existed within ADAM to handle the I/O 
functions associated with the computational routines; therefore, it was 
necessary to write specific assembly language programs to accomplish 
the task. These programs were entered into the ADAM system in the 
same manner as the mathematical routines. 

The computational processes were very special cases of data 
manipulation used in the assignment model. A more conventional 
application of data manipulation existed in the posting of assignments 
and updating of the data base. Assignments made by the assignment 
model were placed in an ADAM file. These assignments had to be 
reflected in the records of the appropriate men and jobs. A cross-file 
reference and update was necessary to accomplish changes to the man 
and job files. 

ASSIGNMENT POSTING AND UPDATING 

FABLE was selected to accomplish the tasks of posting and updating. 
It let the user/designer formulate queries to do the necessary cross¬ 
file referencing and subsequent posting of data in a single step. The 
posting was based on the assignment results. Each job to which a man 
had be en assigned had to be located in the master file of jobs, similarly, 
each man had to be located in the master file of men. Appropriate data 
(e. g. man identification, projected date of assignment, etc. ) was stored 
from the man record into the job record. Similarly, job data (e. g. job 
number, projected date of assignment, etc. ) was placed in the man's 
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record. All these operations were required t. .cccrd projected assign¬ 
ments in the master files. The updating function consisted of advancing 
the time frame of the model, checking the projected date of assignment 
of each record in the man and job files, and if appropriate, transferring 
projected assignment data into "current assignment" data fields of the 
new records. For assignments cf large numbers oi men and jobs each 
function involved large amounts of data and required retri val of data 
from the rather large master files. 

DATA REPORTS 


The final product of the assignment prototype was information which 
had to be transmitted at some point to the user. Since the model was an 
cxperimentnltool, more information was required from the system by the 
user than just assignment results. In some cases the form and timeliness 
of the information often were important to the user. For example, 
special formats were prepared to report the assignment results together 
with man and job data from the master files. Because ADAM's capability 
for formatting output was flexible, but somewhat difficult to use efficiently, 
the standard formats generated by the ADAM system were used to report 
most data on the model. 

The timeliness of the data required by the user was an important 
aspect of the experimental prototype. Recall from earlier discussions 
that data-base systems can have two computing modes associated with 
them -- on-line and off-line. Both modes were utilized in the development 
of the assignment model. The elements of the system were developed 
and checked out in the off-line mode. The use of the model then, in an 
on-line mo r ’-, allowed an effective and comprehensive solution to the 
timeliness of the data the user sees. In addition, on-line operation 
ma *e the user an integral part of the model at experimentation time. 

MAN/MACHINE INTERACTION IN MAN-JOB-MATCH 

To conclude the discussion of the assignment model development, 
a short explanation of the man/machine interaction features of the model 
is appropriate. The model is structured in functional components each 
having assignment parameters or information the user might desire to 
manipulate. Ln the on-line mode, the user can enter messages by 
typewriter, push-button, and/or light-gun actions. The push buttons and 
light gun are input devices associated with a cathode ray tube; i. e. , a 
display scope. He may receive information on the printer, typewriter, 
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or cathode ray tube. The model is supplied with 3 set of queries 
associated with push-buttons which are considered to be standard for 
the system, regardless of policy changes. To initiate an assignment 
cycle, the user, who in this case is a personnel manager or specialist, 
executes the stored queries for obtaining available men and determining 
vacant jobs. He may at this time examine the results of these queries 
by displaying the subsetted files on one of the output devices. He then 
may choose to alter availability or vacancy criteria by changing the 
appropriate string substitutions which comprise the availability or 
vacancy queries. If so, he must delete the current subset of men 
and jobs and again execute the queriejs; which now include his modifica¬ 
tions. Normally, the altering of string substitutions is done by 
typewriter. 

The manager can now initiate the qualification process. This is 
initiated by push-button action. The policy files, both for mandatory 
requirements and qualification criteria, are created prior to the 
assignment run. The manager may choose to alter the policy files at 
any time by light -gun actions associated with push-button activated 
queries, or through typewriter-entered messages. The results of the 
qualification procedure can be reviewed just as the available men and 
vacant jobs were. / 

The assignment process may be initiated by push-button action and 
is subsequent to the qualification process. The assignment results can 
be displayed by the manager for his evaluation. Hard copy and cathode 
ray tube (CRT) displays are generally requested, The manager can 
make general comments about an abbreviated CRT display immediately 
and may desire to examine the results and associated data about men 
and jobs more closely. At this point, the manager can make a decision 
about the assignment results which will determine his next step. He 
may accept the model produced assignments. If he does, he initiates 
the posting and updating queries which are associated with push-buttons. 
The updating will move the time frame on the model so that the next 
cycle of the model will select different men and jobs. If he does not 
accept the assignments, he may elect to do any or all of the several 
options allowed him with regard to personnel policy: 

1. change availability or vacancy criteria to alter the subsets 

2. change mandatory or qualification policy 

3. arbitrarily select a group of men and jobs for assignment action 
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After selecting the appropriate option or updating, the personnel 
manager can exercise the entire model again. This interaction with 
the basic elements of design at every point in the assignment process 
permits the personnel manager to use the prototype to design his 
final system. 

Appendix I is Phase I of a script used in demonstrating the basic 
assignment model as an on-line prototype. The events covered in 
Phase I are those necessary to accomplish an assignment cycle and to 
display selected data associated with those events. Phase I, in 
conjunction with subsequent phases which demonstrate the capability 
to incorporate changes to the model, shows how a personnel manager 
can exercise the model in accordance with the dictates of changing 
policy. 

It is important at this point to emphasize that the man/machine 
interaction supplies the capability to accomplish the final three stages 
of the design/test/evaluate/redesign cycle. In the Man-Job-Match 
problem the testing and evaluation take the form of a structured 
experiment. A specialist in the personnel assignment field institutes 
policies which he deems appropriate and causes assignments to be made. 
His professional opinion, which is supported by experience in making 
personnel assignments, is the basis for evaluating the results. Changes 
to the prototype, whether to the policies or routines, will effect a change 
in the final system's design. Subsequent repetitions of this cycle will 
evolve the design to a status which is appropriate for implementing 
within an operational environment. 

CONCLUSION 


By using ADAM to build a prototype of an officer assignment system, 
the personnel manager and the system designer have a test bed on 
which to verify their design. Such a prototype provides two important 
functions: 

1. a means of communication of requirements between an operational 
user and a system designer 

2. a mechanism for identifying the elements of a design which are 
most frequently changed. 
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The Man-Job-Match project has completed the building of a prototype 
within the ADAM system. Extensive testing of the prototype utilizing 
personnel specialists and real data began in the summer of 1966. Even 
when this testing leads to a final design, such a design still must i. e 
translated into an operational system. Such an operational system will be 
one of the first data-base systems developed along the classic approach 
of design, test, evaluate, and redesign. The key to such an approach 
for data-base systems is the availability of proper test vehicles such 
as ADAM. The effectiveness of ADAM as a design tool has been tested 
with the Man-Job-Match project. When the prototype built in ADAM 
has led to the design of a successful operational system, then the users 
and designers of future information systems wili have both a proven 
new design tool and a different development approach. 
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APPENDIX I 


MAN-JOB-MATCH DEMONSTRATION SCRIPT 
MODEL I 


Phase I - Basic Model Assigning Lieutenants. 

ITEM/PUSH BUTTON RESULTING ACTION/REMARKS 


1. EInter via typewriter: LET SHOW MEAN (D1 D2). This allocates the 
display units to be used in the demonstration 


2. 3,11 

3. 3,1 2 

•4. 3,13 

5. 4,11 

6. 4,12 

7. 4,13 

8. 5,11 

9. 5,12 


Deletes the current subset of the MAN file, 
(MANAVAIL file) from the model. 

Subsets the MAN file in accordance with the 
criteria for determining the availability of 
men for reassignment. This subset becomes 
the new MANAVAIL file. 

Displays the MANAVAIL file. 

Deletes the current subset of the JOB file 
(JOBAVAIL file) from the model. 

Subsets the JOB file in accordance with the 
criteria for determining the job vacancies. 

This subset becomes the new JOBAVAIL file. 

Displays the JOBAVAIL file. 

Initiates the qualification of the men for jobs: 

a. Checking on mandatory job requirements. 

b. Scoring the men on desired qualifications. 

Displays the results of the qualification routine. 
(JMWEIGHT File) 
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ITEM/PUSH DUTTON 
10. 6,11 
11. 6,12 

12. 7,11 

13. 7,12 

14. 7,13 

15. 8,11 

16. 8,12 

17. 8,13 


APPENDIX I CONT'D 

RESULTING ACTION/REMARKS 
Assigns the qualified men to jobs. 

Displays the final assignment matrix. 

Posts the assignments to the MAN and JOB files. 
Displaysthe posted results from the MAN file. 
Displays the posted results from the JOB file. 
Updates the dates in the Man and JOB files. 
Displays the posted dates from the JOB file. 
Displays the posted dates from the MAN file. 
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